网络协议系统梳理

来源：MDN HTTP · MDN TLS · IETF RFCs · IANA

网络协议是计算机网络中设备之间通信的规则和标准。现代互联网建立在分层协议栈 (Layered Protocol Stack)之上，每一层对下层封装的数据进行抽象，向上一层提供服务。核心协议栈是 TCP/IP，对应理论参考模型 OSI。

图 0: 网络协议栈 (Protocol Stack)全景——TCP/IP 四层模型与关键协议

1. 概述

互联网协议的核心设计思想：

术语

2. 行为分析（协议做什么）

2.1 用例图：网络协议的参与者与功能

客户端（浏览器/App）通过协议栈 (Protocol Stack)与远端服务器交互，DNS 负责域名解析，中间路由器只转发 IP 包。

图 2.1: 网络协议参与者用例图

2.2 活动图：数据穿越协议栈 (Protocol Stack)

发送方从上到下逐层封装头部，接收方从下到上逐层解封，每层只处理自己的头部信息。

图 2.2: 数据穿越协议栈 (Protocol Stack)活动图

2.3 时序图：HTTPS 完整请求流程

从 DNS 解析开始，经历 TCP 三次握手 (Three-Way Handshake)、TLS 1.3 握手（1-RTT）、HTTP 请求/响应，到 TCP 四次挥手 (Four-Way Wave)。这是现代 Web 应用最核心的交互模式。

图 2.3: HTTPS 完整生命周期时序图

curl -w "DNS: %{time_namelookup}s\\nTCP: %{time_connect}s\\nTLS: %{time_appconnect}s\\nTTFB: %{time_starttransfer}s\\nTotal: %{time_total}s\\n" \\
     -o /dev/null -s https://www.example.com

2.4 状态机图：TCP 连接状态迁移

TCP 连接从 CLOSED 到 ESTABLISHED 再到 CLOSED，有 11 种状态。服务端通常比客户端多出 LISTEN 和 CLOSE_WAIT 状态。

图 2.4: TCP 连接状态机

3. 结构分析（协议由什么组成）

3.1 包图：OSI 七层 vs TCP/IP 四层模型

OSI 是理论参考模型（7层），TCP/IP 是实际部署模型（4层）。OSI 的会话层 (Session Layer)/表示层 (Presentation Layer)在 TCP/IP 中被合并到应用层。

图 3.1: OSI 七层 vs TCP/IP 四层协议栈 (Protocol Stack)对比

3.2 类图：核心协议头部结构

各层协议的头部（Header）定义了本层的控制信息。以下是 IPv4、TCP、UDP 和 HTTP 消息的头部字段结构。

图 3.2: IPv4、TCP、UDP、HTTP 消息头部结构类图

3.3 部署图：协议栈 (Protocol Stack)在网络节点上的分布

不同网络节点运行的协议层级不同：终端运行完整协议栈 (Protocol Stack)，路由器只运行到网络层（IP），交换机只运行到数据链路层 (Data Link Layer)。

图 3.3: 协议栈 (Protocol Stack)在各网络节点上的部署图

4. 各层协议详解

4.1 IP 协议（网络层）

IP（Internet Protocol）是 TCP/IP 协议栈 (Protocol Stack)的核心，负责寻址和路由 (Addressing and Routing)。它提供"尽力而为 (Best Effort)"的无连接 (Connectionless)数据报 (Datagram)服务——不保证交付、不保证顺序、不保证不重复。

术语

4.2 TCP 协议（传输层——可靠）

TCP（Transmission Control Protocol）在不可靠的 IP 层之上提供可靠的、面向连接 (Connection-Oriented)的、字节流 (Byte Stream)传输服务。由 Vint Cerf 和 Bob Kahn 于 1974 年提出。

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('0.0.0.0', 8080))
s.listen(1)
conn, addr = s.accept()
print(f"Connected: {addr}")
data = conn.recv(1024)
conn.sendall(b"HTTP/1.1 200 OK\\r\\n\\r\\nHello TCP")
conn.close()

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 8080))
s.sendall(b"GET / HTTP/1.1\\r\\nHost: localhost\\r\\n\\r\\n")
print(s.recv(1024).decode())
s.close()

术语

4.3 UDP 协议（传输层——不可靠）

UDP（User Datagram Protocol）提供无连接 (Connectionless)的、不可靠的、数据报 (Datagram)传输。不保证交付，无拥塞控制 (Congestion Control)，头部仅 8 字节。适用于实时应用（VoIP、视频流、在线游戏）和简单查询（DNS）。

4.4 DNS 协议（应用层——域名解析）

DNS（Domain Name System）是互联网的"电话簿"，将人类可读的域名（如 www.example.com）转换为机器可读的 IP 地址。使用 UDP 端口 53（也可走 TCP 53 或 HTTPS/DoH）。

图 4.4: DNS 递归解析流程

DNS 记录类型：

dig +short A example.com          # 查 IPv4
dig +short AAAA example.com       # 查 IPv6
dig +short MX example.com         # 查邮件服务器
dig +trace example.com            # 跟踪递归解析全过程
nslookup example.com              # Windows 风格查询

术语

4.5 TLS 协议（会话层 (Session Layer)——传输安全）

TLS（Transport Layer Security）在 TCP 之上提供加密、完整校验 (Integrity)和身份认证 (Authentication)。最新版本 TLS 1.3（RFC 8446）将握手从 2-RTT 优化为 1-RTT。

TLS 1.3 握手流程（1-RTT）：

1. ClientHello：发送支持的密码套件 (Cipher Suite) + 密钥共享 (Key Share)（DH 公钥）
2. ServerHello：选择密码套件 (Cipher Suite) + 密钥共享 (Key Share) + 证书 + Finished（已加密）
3. Client Finished：验证证书，发送 Finished（已加密）
4. 握手完成，开始传输应用数据（Application Data）

4.5.1 X.509 数字证书详解

证书的本质：一个符合 X.509 标准的二进制结构，包含以下核心字段：

核心原理：CA 用自己的私钥对证书内容做数字签名 (Digital Signature)。客户端用 CA 的公钥验签，若通过则证明"证书内容未被篡改，且该公钥确实属于 Subject"。这是信任链 (Chain of Trust)的根基。

4.5.2 PEM 格式

PEM（Privacy-Enhanced Mail）是最常见的证书编码格式。本质是 DER 二进制内容的 Base64 编码，用 -----BEGIN/END----- 头尾包裹，方便文本传输和粘贴。

-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDQgK2A...
... (Base64 encoded DER) ...
-----END CERTIFICATE-----

明文查看 PEM 内容：

openssl x509 -in cert.pem -text -noout

4.5.3 证书存储位置

4.5.4 实战：生成与使用证书

1. 生成私钥：

# ECDSA (推荐，性能好，密钥小)
openssl ecparam -genkey -name prime256v1 -out server.key

# RSA 2048 (兼容性最好)
openssl genrsa -out server.key 2048

2. 生成 CSR（证书签名请求）：

openssl req -new -key server.key -out server.csr \
  -subj "/C=CN/ST=Guangdong/L=Shenzhen/O=MicroArch/CN=*.example.com"

3. 自签名证书（开发/测试用）：

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -days 365 -nodes \
  -keyout server.key -out server.crt \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:*.local"

4. 查看证书内容：

openssl x509 -in server.crt -text -noout    # 全部字段
openssl x509 -in server.crt -dates -noout   # 仅有效期
openssl x509 -in server.crt -subject -noout # 仅 Subject
openssl x509 -in server.crt -fingerprint -sha256 -noout  # 指纹

5. 验证证书链：

# 验证服务器证书是否由指定 CA 签发
openssl verify -CAfile ca-bundle.crt server.crt

# 查看远端服务器证书链
openssl s_client -connect example.com:443 -showcerts /dev/null \
  | openssl x509 -text -noout

# 检查证书过期时间
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

6. Nginx 配置 TLS：

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com/fullchain.pem;  # 证书+中间CA
    ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;    # 私钥
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;  # TLS 1.3 由客户端优先
}

7. 格式转换：

# PEM → DER
openssl x509 -in cert.pem -outform der -out cert.der

# PEM → PKCS#12 (含私钥)
openssl pkcs12 -export -in cert.pem -inkey server.key -out cert.pfx

# 查看 Java cacerts 中的证书
keytool -list -v -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit

4.5.5 证书信任模型

自签名 vs CA 签名：任何人都可以用 OpenSSL 生成自签名证书，无需经过任何第三方。区别在于：自签名证书浏览器会弹"不安全"警告，因为没有 CA 背书；CA 签名证书浏览器信任，显示绿色锁。内网/开发用自签名完全够，公网面向用户则需 CA 签发。

图 4.5.5: 自签名 vs CA 签名证书信任模型对比

CA 背书是什么：CA（Certificate Authority，证书颁发机构）用它的私钥给你的证书做数字签名 (Digital Signature)——相当于"盖个章"。浏览器/操作系统内置了受信任 CA 的公钥，访问网站时用这个公钥验签：签名验证通过则说明"该证书确实由我信任的 CA 签发，未被伪造"，于是显示绿色锁。

为什么需要 CA：公钥本身没法证明"我是谁"。任何人都能把公钥和一个域名写进证书，然后自称是 google.com。浏览器接到这个证书后无法判断真假——它需要一个自己本来就信任的第三方来担保。CA 在签发前会验证你对域名有控制权，所以浏览器信任 CA 的判断。根子上是个信任传递 (Transitive Trust)问题：你不可能认识互联网上所有服务器，但你认识操作系统里预设的那几百个 CA。

根证书为什么不能伪造：你伪造一个根证书，写上"我是 CA"，但浏览器会用它内置的根 CA 公钥去验证——这个公钥是编译进操作系统/浏览器的，不修改源码就换不掉。而伪造的证书和真 CA 的私钥不匹配，签名验证直接失败。根证书的安全不靠证书本身，靠的是：私钥在 CA 手里不泄露 + 浏览器预先写死公钥。两个卡住一个就通不过。

证书为什么有免费的也有收费的：

云厂商收费除 OV/EV 人工审核成本外，还附带赔付保险（证书泄露导致钓鱼损失可索赔数十万）和技术支持。普通个人/小站点用 Let's Encrypt 足够了，大企业银行才需要 OV/EV。

术语

4.6 HTTP 协议（应用层——超文本传输）

HTTP（Hypertext Transfer Protocol）是 Web 的基础。采用请求-响应 (Request-Response)模型，典型工作流：

1. 建立 TCP/TLS 连接
2. 发送 HTTP 请求消息
3. 读取服务器返回的 HTTP 响应消息
4. 关闭或复用连接

HTTP 请求格式：

METHOD /path HTTP/1.1
Header-Name: value
Header-Name: value
[空行]
[可选请求体]

HTTP 响应格式：

HTTP/1.1 200 OK
Header-Name: value
Content-Type: text/html
[空行]
<!DOCTYPE html>...

常用请求方法：

HTTP 核心特性：

fetch('https://api.example.com/users', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ name: 'Alice', email: 'alice@example.com' })
})
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => console.error('Error:', err));

术语

4.7 HTTP/2 & HTTP/3（QUIC）

图 4.7: HTTP/1.1 → HTTP/2 → HTTP/3 演进对比

术语

4.8 SSE 服务器推送（Server-Sent Events）

SSE 是 HTTP 标准的一部分（HTML Standard / text/event-stream），允许服务器通过一个持久的 HTTP 长连接 (Persistent Connection)单向向客户端推送数据流。与 WebSocket 不同，SSE 仅支持服务器 → 客户端方向，但不需要协议升级 (Protocol Upgrade)，天然兼容 HTTP 基础设施（代理、CDN、认证 (Authentication)）。

SSE 数据格式（text/event-stream）：

event: update\n
id: 42\n
data: {"price": 18.5, "change": +0.3}\n
\n
data: {"price": 18.7, "change": +0.2}\n
\n

字段说明：data: 定义消息体；event: 自定义事件名；id: 消息编号（用于断线重连）；空行（\n\n）表示消息边界。

const http = require('http');
http.createServer((req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive',
    'Access-Control-Allow-Origin': '*'
  });
  let id = 0;
  setInterval(() => {
    res.write(`id: ${++id}\\n`);
    res.write(`data: ${JSON.stringify({ time: Date.now(), id })}\\n\\n`);
  }, 1000);
}).listen(3000);
console.log('SSE server on http://localhost:3000');

const es = new EventSource('http://localhost:3000');
es.onmessage = (e) => console.log('Message:', JSON.parse(e.data));
es.onerror  = () => console.log('Disconnected, auto-reconnecting...');
// 自定义事件监听
es.addEventListener('update', (e) => console.log('Update:', e.data));
// 关闭连接
// es.close();

图 4.8: SSE 服务器推送时序图

4.9 WebSocket 协议

WebSocket（RFC 6455）提供全双工 (Full-Duplex)、低延迟、持久的双向通信通道。它通过 HTTP Upgrade 机制从 HTTP/1.1 升级到 ws:// 或加密 wss:// 协议，之后数据以帧（Frame）的形式双向传输，不再有 HTTP 头部开销。

const { WebSocketServer } = require('ws');
const wss = new WebSocketServer({ port: 8080 });
wss.on('connection', (ws) => {
  console.log('Client connected');
  ws.on('message', (data) => {
    console.log('Received:', data.toString());
    ws.send(`Echo: ${data}`);
  });
  ws.send('Welcome to WebSocket server');
});

const ws = new WebSocket('ws://localhost:8080');
ws.onopen  = () => { ws.send('Hello Server!'); };
ws.onmessage = (e) => console.log('Received:', e.data);
ws.onclose = () => console.log('Disconnected');
ws.onerror = (e) => console.error('Error:', e);
// ws.close();

图 4.9: WebSocket 握手与通信时序图

术语

4.10 网络代理 (Proxy)

代理服务器（Proxy）是介于客户端与目标服务器之间的中转节点。根据部署方向和使用场景，分为正向代理 (Forward Proxy)和反向代理 (Reverse Proxy)两大类。

4.10.0 程序为什么会走代理

程序走代理的本质是：不直接连目标服务器，而是先连代理服务器，让代理帮你转发请求。实现方式分两种：

1. 程序自己读代理配置（显式代理 (Explicit Proxy)）：

程序启动时检查环境变量 http_proxy / https_proxy 或自身配置文件。如果配了代理，就直接把请求发到代理地址而不是目标地址。curl、git、npm、pip 等工具都遵循这套约定——遍历 proxy 类环境变量，有就发给代理，没有就直连。

# 底层原理（以 curl 为例，伪代码）
target = "https://example.com"
proxy  = getenv("https_proxy")       # http://127.0.0.1:8080
if proxy:
    tcp_connect(proxy)               # 连代理 127.0.0.1:8080
    send("CONNECT example.com:443")  # 让代理去连目标
else:
    tcp_connect("example.com:443")   # 直连目标

2. 系统层劫持流量（透明代理 (Transparent Proxy) / TUN）：

程序以为自己直连目标，实际上操作系统或网络设备在内核层把流量拦截下来，重定向到代理。

方式一：iptables REDIRECT / TPROXY

利用 Linux 内核的 Netfilter 框架，在数据包经过协议栈 (Protocol Stack)时用 iptables 规则匹配并改写目标地址：

# 将所有出站 TCP 80/443 流量劫持到本地 8080 端口
iptables -t nat -A OUTPUT -p tcp --dport 80  -j REDIRECT --to-port 8080
iptables -t nat -A OUTPUT -p tcp --dport 443 -j REDIRECT --to-port 8080

数据包路径：

1. 程序调用 connect("example.com:443")，内核构造 SYN 包，目标 = example.com:443
2. 包经过 OUTPUT 链 nat 表，命中 REDIRECT 规则，目标地址被改写为 127.0.0.1:8080
3. 包到达本地 8080 端口（代理程序在监听）
4. 代理收到连接后，通过 getsockopt(SO_ORIGINAL_DST) 获取原始目标地址，然后自己去连真正的 example.com:443

关键：改写发生在内核 netfilter，用户态程序完全不知情。程序以为自己连了 example.com，实际 TCP 连接被偷换成了代理。REDIRECT 只适用于代理在本机；跨机器的网关场景用 TPROXY（保留原始目标地址不修改）。

方式二：路由 + TUN 虚拟网卡

大多数翻墙代理（Clash、Shadowsocks、v2ray）用的方案：

# 虚拟网卡 tap/tun 是什么
ip tuntap add tun0 mode tun           # 创建虚拟三层网卡（无 MAC，纯 IP）
ip addr add 198.18.0.1/16 dev tun0    # 配 IP
ip link set tun0 up                   # 启用
ip route add default via 198.18.0.1 dev tun0 metric 1   # 默认路由走虚拟网卡

机制：

1. 程序调用 send(sock, http_request)，数据经内核 TCP/IP 栈封装成 IP 包
2. 内核查路由表，匹配到 default via 198.18.0.1 dev tun0，把 IP 包写入 /dev/net/tun 字符设备
3. 代理程序从 /dev/net/tun 的 fd 里 read() 读出原始 IP 包
4. 代理解析包中的目标 IP:Port，自己建加密隧道连远端服务器，把 IP 包转发过去
5. 远端代理解包，以原始目标建 TCP 连接，把 payload 写入 → 响应原路返回

TUN 工作在网络层（IP 包），能劫持所有协议（TCP/UDP/ICMP 全部一刀切）。TAP 工作在链路层（以太帧），多一层 MAC 头，一般用于 VPN 做二层隧道。代理程序收到的就是完整的原始 IP 包，需要自己实现 TCP 状态跟踪。

图 4.10.0: iptables REDIRECT vs TUN 虚拟网卡流量劫持对比

方式三：浏览器 PAC（Proxy Auto-Config）

浏览器从 PAC URL 下载一个 JavaScript 文件，里面有 FindProxyForURL(url, host) 函数。浏览器每次发请求前调用这个函数，根据返回值决定：

function FindProxyForURL(url, host) {
    if (shExpMatch(host, "*.internal.com")) return "DIRECT";              // 直连
    if (shExpMatch(host, "*.google.com"))   return "PROXY 127.0.0.1:1080"; // 走代理
    return "SOCKS5 127.0.0.1:1080";                                       // 默认走 SOCKS5
}

PAC 只是"决策脚本"，不劫持流量——浏览器拿到决策后自己选择连代理还是直连，跟显式代理 (Explicit Proxy)本质一样，只是规则自动化了。

对比三种方式拦截点：

对比：

一旦流量进入代理（不管是显式还是透明），后续都是：客户端 ↔ 代理 ↔ 目标服务器，代理做 TCP 字节流 (Byte Stream)转发（正向代理 (Forward Proxy)）或按规则路由到后端（反向代理 (Reverse Proxy)）。

各语言 HTTP 库代理支持一览：大部分主流语言的标准库或常用 HTTP 库已封装好代理逻辑，开发者写业务代码一般不用自己处理。有代理就走，没有就直连。

本质都是同一条链路：

程序 → 读环境变量/配置 → 有代理就连代理:port → 代理转发到目标
                          → 无代理就直连目标

代理判断逻辑在用户态 HTTP 库里，内核只负责建 TCP 连接，不关心连接的是代理还是目标。

4.10.1 正向代理 (Forward Proxy) vs 反向代理 (Reverse Proxy)

图 4.10.1: 正向代理 (Forward Proxy) vs 反向代理 (Reverse Proxy)部署差异

4.10.2 代理协议类型

4.10.3 HTTP CONNECT 隧道机制

浏览器访问 HTTPS 网站时，首先向代理发送 CONNECT 请求建立隧道，之后所有流量（包括 TLS 握手和加密数据）透明穿透代理，代理只做 TCP 字节流 (Byte Stream)转发，无法解密内容（区别于 MITM 代理）。

图 4.10.3: HTTP CONNECT 隧道建立时序

# 客户端 → 代理：建立隧道
CONNECT example.com:443 HTTP/1.1
Host: example.com:443

# 代理 → 客户端：隧道已建立
HTTP/1.1 200 Connection Established

# 此后客户端 ↔ 服务器直通（经代理 TCP 转发）
# TLS 握手、HTTP 请求全部透明穿透

4.10.4 实战操作

1. 命令行使用代理：

# HTTP/HTTPS 代理
export http_proxy="http://127.0.0.1:8080"
export https_proxy="http://127.0.0.1:8080"
export no_proxy="localhost,127.0.0.1,.internal.local"

# SOCKS5 代理 (curl)
curl --socks5 127.0.0.1:1080 https://example.com

# Git 代理
git config --global http.proxy http://127.0.0.1:8080
git config --global http.proxy socks5://127.0.0.1:1080

# SSH 通过代理连接 (ProxyJump / ProxyCommand)
ssh -o ProxyCommand='nc -X 5 -x 127.0.0.1:1080 %h %p' user@remote
# 或 ~/.ssh/config:
# Host remote
#   ProxyJump user@jump-host
#   # 或 ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

2. Nginx 反向代理 (Reverse Proxy)配置：

# L7 HTTP 反向代理
server {
    listen 80;
    server_name api.example.com;
    location / {
        proxy_pass http://backend:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# L4 TCP 反向代理 (Stream 模块, 需编译 --with-stream)
stream {
    upstream mysql_backend {
        server 10.0.1.10:3306;
        server 10.0.1.11:3306 backup;
    }
    server {
        listen 3306;
        proxy_pass mysql_backend;
        proxy_connect_timeout 5s;
    }
}

# SSL 卸载（反向代理终结 TLS，后端 HTTP）
server {
    listen 443 ssl http2;
    server_name example.com;
    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    location / {
        proxy_pass http://backend:3000;    # 后端只需 HTTP
    }
}

3. 代理环境变量说明：

4.10.5 MITM 调试代理工具

上述代理（正向/反向）只做透明转发 (Transparent Forwarding)，不解密流量。而开发调试中经常需要查看和修改加密的 HTTPS 内容，此时需要使用 MITM（Man-in-the-Middle）代理工具。它们通过在本机安装自签 CA 根证书，以中间人身份解密 HTTPS，让开发者可以检查、修改、重放 HTTP 请求。

图 4.10.5: 正向代理 (Forward Proxy)（透明转发 (Transparent Forwarding)） vs MITM 代理（解密检查）对比

MITM 工作原理：

1. 客户端信任 MITM 代理的自签 CA 证书（手动安装到系统/Browser 信任库）
2. 客户端连接代理，发起 CONNECT 请求
3. 代理与目标服务器完成真实的 TLS 握手（代理 → 服务器端）
4. 代理用自签 CA 动态签发一个伪造的目标域名证书，与客户端完成 TLS 握手（客户端 → 代理端）
5. 代理持有两段 TLS 会话的密钥，可解密、查看、修改双向流量

# mitmproxy 快速上手
brew install mitmproxy            # 安装
mitmweb                          # Web UI 模式 (http://localhost:8081)
# 或 mitmproxy (CLI TUI 模式)

# 设置系统代理指向 mitmproxy 默认端口 8080
export https_proxy="http://127.0.0.1:8080"

# 首次使用需安装证书：浏览器访问 http://mitm.it

# Charles / Proxyman：GUI 工具直接启动，自动配置系统代理

术语

5. 实战速查手册

5.1 常见端口

5.2 HTTP 状态码速查

5.3 常用调试命令

    time_namelookup:  %{time_namelookup}\\n
       time_connect:  %{time_connect}\\n
    time_appconnect:  %{time_appconnect}\\n
   time_pretransfer:  %{time_pretransfer}\\n
      time_redirect:  %{time_redirect}\\n
 time_starttransfer:  %{time_starttransfer}\\n
                    ----------\\n
         time_total:  %{time_total}\\n

参考文献

• RFC 791 — Internet Protocol (IP)
• RFC 793 — Transmission Control Protocol (TCP)
• RFC 768 — User Datagram Protocol (UDP)
• RFC 1035 — Domain Name System
• RFC 8446 — TLS 1.3
• RFC 9110 — HTTP Semantics
• RFC 9113 — HTTP/2
• RFC 9114 — HTTP/3
• RFC 8999 — QUIC
• MDN — HTTP Overview
• MDN — Transport Layer Security
• MDN — TCP Glossary
• MDN — DNS Glossary
• Wikipedia — Internet Protocol Suite
• Wikipedia — OSI Model